Method and system for automatically generating a global simulation model of an architecture

ABSTRACT

The present invention relates to a method and a system for generating a global simulation model of an architecture. In particular, the invention relates to a method of automatic generation, by means of a data processing system associated with a program called a Configurator for creating a global simulation model of an architecture comprising models of integrated circuits under development, comprising:  
     reading an architecture description file of the global model and storing information related to all of the possible configurations;  
     instantiating the components and storing the corresponding information in an instance connection table;  
     topologically connecting the interface signals,  
     physically connecting the interface signals, at the level of each instance of the components using a component and connection rule table, and storing the corresponding information in a wiring table; and  
     automatically generating the HDL-type and HLL-type source files of the global simulation model, corresponding to the configuration specified by the configuration definition file.

[0001] The invention concerns a method and a system for generating aglobal simulation model of an architecture. More particularly, theinvention concerns a configuration method and a system called a“Configurator” for implementing the method.

[0002] With the increasing complexity of hardware systems, it isnecessary, in order to verify systems or integrated circuits underdesign, to be able to handle configurations that increasingly includemodels written in a hardware description language, for example of theHDL type (such as VDHL or Verilog, the most widely used), and in a highlevel languages of the HLL type (such as C or C⁺⁺); these languagesdescribe, on the one hand, the elements constituting the hardware, andon the other hand, the models constituting the simulation environment.

[0003] The term “Configuration” will be used to refer to a set ofsoftware models of elements called “Components,” constituting a globalsimulation model.

[0004] The invention can be used to verify the design of ASICS bysimulating their operation, for example in an environment identical orvery similar to their end use, the configuration method making itpossible to choose components and their software models from a pluralityof available models in order to create simulation configurations. In theprior art, the configurations are rigid, and traditionally prepared “byhand” using text editors or graphics editors, based on a predefined listof possible configurations. Each modification in the model in HDLlanguage requires manual corrections to be incorporated into all of theconfigurations. This happens several times during the development of anASIC and constitutes a source of errors and modification problems,resulting in production delays. Modifications of a configuration areoften sources of errors that are hard to find, as the size of someconfigurations can reach tens of thousands of lines, making themdifficult to handle manually.

[0005] The time required to write and debug a configuration can be verylong, making it difficult to generate and add new configurations intothe environment. For that reason, when an environment contains a lot ofelements for which it is difficult to predict all of the usableconfigurations, the use of certain configuration variants thatfacilitate debugging (simplified target configurations, for example) isoften avoided.

[0006] These problems are accentuated in the more and more widely usedco-simulation environments, wherein the models come from differentsources and are written in high level programming languages (HLL) suchas C or C⁺⁺, or in hardware description languages (HDL) such as VERILOGor VHDL. For the same component of the configuration, there are oftenseveral models (ex: functional, in high level programming languages;behavioral, in HDL, synthesizable HDL, etc.) that it would be desirableto be able to use transparently, as needed.

[0007] Moreover, the models to be connected often have, at the level ofthe connecting interfaces, differences requiring the use of adaptationmodules. This is the case, for example, for circuits with sophisticatedinput/output interfaces for which the logical level of the protocol issimulated first, the physical level being developed near the end of theproject. The ability to choose adaptation models for the variants of HDLinterfaces corresponding to the various development phases of theproject constitutes an additional degree of freedom that complicates thewriting of the configurations even more. Another problem stems from thefact that mixed HDL (for example Verilog or VHDL)/HLL (for example C++)type models developed separately must be updated coherently. In the caseof nonautomated management, this is a potential source of errors.

[0008] The object of the present invention is to limit one or more ofthese drawbacks.

[0009] To this end, the invention primarily concerns a method ofautomatic generation, by means of a data processing system associatedwith a program called a Configurator for creating a global simulationmodel of an architecture comprising models of integrated circuits underdevelopment that can constitute, with the help of the automaticConfigurator, a machine or a part of a machine, and environmentsimulation models that make it possible to test and verify the circuitunder development, a configuration definition file for components of thearchitecture, these components constituting fixed functional blocks fordescribing the functionalities of integrated circuits or parts ofintegrated circuits, the components being chosen by the user from alibrary of various component types and a library of environmentcomponents, in order to create the global model of the architecturecorresponding to the functional specification defined in theconfiguration definition file and conforming to the specification of thearchitecture of the global model specified by an architecturedescription file, a method characterized in that it includes thefollowing steps:

[0010] the reading of the architecture description file of the globalmodel and the storage, in a component and connection rule table, in aconnection coherency rule table, and in a source file formatting table,of information related to all of the possible configurations, eachcomponent obtaining an name that unambiguously identifies its positionin the architecture, and a type from among several types (ActiveComponents, Monitoring and Verification Blocks, Intermediate Blocks,System Blocks and Global Blocks),

[0011] the instantiation of the components specified in theconfiguration definition file by the user-developer using a list of thecomponents present, designated by their names and types and includingparameters or invoking procedures, the configuration definition filecomprising a file from which to select the components and their typesand optional additional indications concerning the type of interface andthe server involved in the configuration to be generated by theConfigurator, and the storage of the corresponding information in aninstance connection table,

[0012] the topological connection of the instances and the storage ofthe corresponding information in an instance connection table,

[0013] the physical connection of the interface signals, at the level ofeach instance of the components, by applying regular expressions, storedin the component and connection rule table, based on the names of thesignals constituting a wiring table,

[0014] the use of the instance connection table, the wiring table andthe formatting table to automatically generate HDL-type and HLL-typesource files of the global simulation model corresponding to theconfiguration specified by the configuration definition file.

[0015] According to another characteristic of the method, theConfigurator system transmits to the HLL-type parts of each componentinformation on:

[0016] the name of the component;

[0017] the type of the instance

[0018] the HDL path, i.e. the hierarchical name of the component in thedescription of the model.

[0019] According to another characteristic of the method, theconfiguration definition file also includes a keyword indicating thename or number of the server in which a component is instantiated, whenthe method is used in a multi-server system.

[0020] According to another characteristic of the method, in the case ofa multi-server utilization, the Configurator system executes thefollowing steps:

[0021] the division of the Configuration into several (HDL-type andHLL-type) parts, sorting the HDL-type components and the HLL-typeobjects according to the servers to which they belong,

[0022] the generation of the HDL-type peripheral components used forsending and receiving signals between the parts of the configuration,

[0023] the duplication of the Global Blocks by the Configurator systemand the instantiation of the Global Blocks duplicated in each server,

[0024] the generation of HLL-type parts that serve as a communicationmedium between the servers.

[0025] According to another characteristic of the method, the automaticconnection between the components by the Configurator system includesseveral phases:

[0026] a high-level topological phase for selecting the components andtheir respective positions,

[0027] a wiring phase for creating the actual connection between thecomponents, this phase generating as a result a wiring table thatassociates the signals connected to one other with the unique name ofthe wire that connects them,

[0028] a phase for generating HDL-type and HLtL-type source files.

[0029] According to another characteristic of the method, the wiringphase is performed by the Configurator system in the following threesteps:

[0030] a. the Global Blocks and the System Blocks are first connected toall of the components,

[0031] b. next come the connections of the signals between the othercomponents,

[0032] c. after the wiring, an additional pass makes it possible toconnect the remaining unconnected signals of each component topredetermined signals in order to produce a given stable state; theConfigurator system then generates partial configurations comprising asubset of the architecture.

[0033] According to another characteristic of the method, thepredetermined signals are the signals of the System Block correspondingto the component.

[0034] According to another characteristic, the description file of thearchitecture of the global model includes the simulation models of the.Global Blocks and the System Blocks, these two types of components beingconnected to one another and handling environment signals.

[0035] According to another characteristic, the System Blocks areconnected to the other components and supply them with the systemsignals that are specific to them.

[0036] According to another characteristic of the method, the dataprocessing system performs a conformity check of the connections,comparing the connection table of the real instances between blocks tothe connection coherency rule table.

[0037] According to another characteristic of the method, the dataprocessing system compares the physical connections between thecomponents to the connection coherency rule table, in order to detectany incompatibilities between the ends of the connections between thecomponents, and in such a case, it specifies, and adds into the instanceconnection table, an adapter component inserted into the connection inquestion.

[0038] According to another characteristic, the configuration definitionfile includes information, specified by an attribute, concerning theutilization of adapter components with the instances of the activeComponents, whose connections are compared to the instance connectiontable in order to detect any incompatibilities between the ends of theconnections between the components, and in such a case it specifies, andadds into the instance connection table, another adapter componentinserted into the connection in question. According to anothercharacteristic of the method, the data processing system selects certainconnections between the components of the connection coherency ruletable and specifies, and adds into the instance connection table,additional connections constituting branches leading to respectiveadditional models, which represent tools for monitoring the connections.

[0039] According to another characteristic of the method, in the sourcefile generation phase, the Configurator system generates the sourcefiles in HDL language and in HLL language, based on the content of thecomponent and connection rule table, the connection coherency ruletable, the source file formatting table, the instance connection tableand the wiring table.

[0040] According to another characteristic of the method, the dataprocessing system executes an operation through the Configurator systemfor each configuration variant, in order to obtain several simulationmodels corresponding to the same functional specification, but writtenin a description comprising various mixtures of languages of differentlevels (HDL, HLL).

[0041] According to another characteristic of the method, the dataprocessing system generates the functional specification of the globalsimulation model in a computer format compatible with a high-levelprogramming language, (HLL) and in a format compatible with a hardwaredescription language (HDL).

[0042] According to another characteristic of the method, theconfiguration definition file comprises, for each component, at leastone part in HDL-type language, said part in HDL-type language providingan interface with other models.

[0043] According to another characteristic of the method, the modelsthat include a part in HLL-type language include interface adapters.

[0044] According to another characteristic, the Configurator systemchooses each interface adapter model as a function of the connectioncoherency rule table.

[0045] According to another characteristic of the method, theconnections of the physical signals are specified by “Ports,” each portbeing an arbitrary selection of signals from the HDL-type interface of acomponent by means of regular expressions based on the names of thesesignals, and being constituted by regular expression/substituteexpression pairs, these expressions being successively applied to thename of each signal of the HDL-type interface, and if the finalsubstitution is identical for two signals, the latter are connected toone another, the connection being stored in the wiring table.

[0046] According to another characteristic of the method, each interfaceadapter being shared among several models connected to the same port,only one of these models transmits signals through said port.

[0047] Another object of the invention is to offer a Configurator systemthat makes it possible to eliminate one or more of the precedingdrawbacks.

[0048] This object is achieved by the data processing system forautomatically generating a global simulation model of a configuration offixed functional blocks, mutually connected by interworking connectionsso as to constitute the global simulation model of an architecturecomprising models of integrated circuits under development that canconstitute a machine that conforms to the functional specification of aconfiguration, this system being characterized in that the dataprocessing system uses a Configurator program that includes means forcreating a simulation of the wiring by applying stored regularexpressions, and for using a configuration definition file in a highlevel language, a component and connection rule table describing theproperties (type, HDL-type interfaces, ports, constructors of HLL classobjects, etc.) of the software components for simulating the circuit, aconnection coherency rule table in a high level language (HLL), meansfor instantiating the elements resulting from the configurationdefinition file, and an HLL code generator that combines the parametersof the components with the connection rules. According to anothercharacteristic of the system, there are at least five types ofcomponents: Active Components, Monitoring and Verification Blocks,Intermediate Blocks, System Blocks and Global Blocks.

[0049] According to another characteristic of the system, it is equippedto perform a conformity check of the connections by comparing theinstance connection table with a table of coherency rules for thephysical connections between the models chosen from the blocksconstituting the global model.

[0050] According to another characteristic of the system, it is equippedto compare the connection table of the real instances between blocks tothe connection coherency rule table, in order to detect anyincompatibilities between the ends of the connections between blocks,and in such a case to specify, and add into the coherency rule table ofthe real connections, a functional adapter block inserted into theconnection in question.

[0051] According to another characteristic of the system, the componentand connection rule table, which includes the properties of thecomponents, contains global parameters common to all of the componenttypes and exists in the form of a table distributed into one or moretables, which may or may not be associative, wherein the entries arenames designating all of the possible models for the same component.

[0052] According to another characteristic of the system, theassociative tables can contain the description, either in the form ofparameter sets or in the form of references to procedures that generatethe required values, the entries of these associative tables being namesdesignating all of the possible models for the same component andforming a character string containing predetermined special identifiers,replaced by the values calculated by the Configurator system.

[0053] According to another characteristic of the system, at least threeselectors indicate the instance to be used, the latter being transmittedas a parameter to a constructor of an HLL object.

[0054] a first selector indicates the current instance,

[0055] a second selector specifies the instance connected to the otherend of the port,

[0056] a third selector indicates the composite instance correspondingto the active Component containing the observation port.

[0057] According to another characteristic of the system, theConfigurator system uses one or more connection coherency rule tables,which represent the rules for interconnecting the components and forinserting intermediate components, one or more component and connectionrule tables, which represent the system-level connection rules and therules for generating connections between the signals, and one or moresource file formatting tables, which represent the rules for generatinginstances of HLL-type objects.

[0058] According to another characteristic of the system, theConfigurator system uses:

[0059] an HLL base class for uniquely identifying each objectinstantiated and for polling the configuration,

[0060] means for generating and automatically instantiating SystemBlocks,

[0061] means for tables associating the signals connected together underthe unique name of the connecting wire,

[0062] means for using a formatting table to generate the source filesin HDL and HLL.

[0063] According to another characteristic of the system, the operatorfunctionally specifies the configuration in the highest level languageas much as possible, and completes the functional specification with thecomponents in the lowest level language.

[0064] According to another characteristic of the system, the followingentries in the hash define the component Type (for example DUT (HDLmodel), XACTOR (transactor), MONITOR, VERIFIER or other types), andcorresponds each Component Type to a hash, in turn composed of thefollowing entries:

[0065] a first entry ReqModule contains the name of the HDL module ofthe component and the name of the corresponding source file,

[0066] a second entry Connect is the definition of the method forselecting the signals that are part of a Port, this description beingcomposed of a set of entries indexed by the name of the Port; theconfigurator associates each Port name with a table of regularexpressions and a pointer to a signal connection procedure that controlsthe application of these expressions to the names of the signals of theinterface of the component.

[0067] According to another characteristic of the system, the genericstructure of the active Components includes a Block containing the HDLdescription and a Block in HLL that provides the access paths to the HDLresources, and if necessary, a description of the block in HLL; the setof signals of the HDL block constitute the interface of the containingBlock, formed by Ports, which are arbitrary logical selections of thesignals of an interface, and by interface adapters, which are thesoftware parts that handle, in each Port, the two-way communicationbetween the parts in HLL and those in HDL, the interface adapters beingchosen by the Configurator system.

[0068] According to another characteristic of the system, the Ports arespecified in the form of regular expressions, which serve both to selectthe subsets of signals to be connected and to define the connectionrules.

[0069] According to another characteristic of the system, theConfigurator system generates so-called Transfer Components, which areinserted on each side of the cutoff to the servers, these componentssimply being wires for the inputs and registers for the outputs.

[0070] The elementary model components, which are shared among theComposite Model Components or the Global Blocks belonging to the variousservers, are automatically duplicated by the Configurator system andinstantiated in each server.

[0071] The invention will be better understood with the help of thefollowing description of a preferred embodiment of the method of theinvention, in reference to the attached drawings, in which:

[0072]FIG. 1 represents, in highly schematic form, an exemplaryarchitecture of the global simulation model for an integrated circuit(ASIC) under development, called BRIDGE (12);

[0073]FIGS. 2A through 2D are diagrams illustrating the variouscomponents of the Configurator system and the steps for implementingthese components in the method of the invention;

[0074]FIGS. 3a through 3 c represent various stages in the modeling of acircuit using a mixed HDL (VERILOG or VDHL) type and the HLL (C⁺⁺) typemode;

[0075]FIG. 4 represents the generic structure of an elementary Model;

[0076]FIG. 5 represents the generic structure of a Composite Model;

[0077]FIG. 6 describes the correspondence between the tables of thedescription of the configurator system in FIGS. 2a through 2 d and thetables for implementing the method of the invention;

[0078]FIGS. 7a through 7 k schematically represent the various models ofthe components with the necessary variants of their interfaces anddescription levels for the configurations related to the architecture inthe example of FIG. 1;

[0079]FIGS. 8a through 8 e represent the successive configurations ofthe architecture that results in the creation of a given model, thefinal model of which corresponds to that of FIG. 8e, for which all ofthe HDL-type models of the circuit under design are available, thisfinal model corresponding to the configuration; FIG. 8f represents thedistribution of the simulation configuration of the model of FIG. 8a,for example into two machines.

[0080] The invention concerns a system called a “Configurator,” and theconfiguration method implemented by the system.

[0081] A global simulation model is typically composed of one or moremodels of integrated circuits under test (DUTs) surrounded by modelsthat create a testing and verification environment. These models createcomplex stimuli and receive complex responses from the model beingtested. These components can be transactors (XACTORS)—models thatgenerally have a program interface (API) that permits control by testsoutside the model, these tests generally being written in a high levellanguage (HLL).

[0082] The verification environment can also contain components calledMonitoring Blocks (MONITOR) and components called Verification Blocks(VERIFIER). These components are not directly involved in the exchangeof signals between the other components of the global simulation model,but are used to observe and interpret them. The Monitoring Blocks(MONITOR) serve as analysis aids for the tests; they have programinterfaces (APIs) for reporting events observed in the signals of theglobal model. The Verification Blocks (VERIFIER) are components thathave a reference specification for the operation of the model beingtested, and by observing the signals of the global simulation model,they are capable of verifying the proper operation of the model.

[0083]FIG. 1 represents an exemplary architecture of an integratedcircuit system under development for which it is necessary, in a firststep, to debug the global simulation model corresponding to FIG. 8c,chosen in order to illustrate the greatest number of mechanismsimplemented by the configurator. It should be clear that the steps inFIGS. 8a, 8 b, could be executed first, depending on the availability ofthe models and the objectives of the verification. The final modeldesired is the one that corresponds to FIG. 8e. The architecture isconstituted by a processor (CPU) communicating through a bridge (BRIDGE)with a system memory (MEMORY) and input/outputs (I/O). The modelproduced by the “Configurator” system of the invention is constituted bya processor component CPU of the XACTOR type, connected by an interfaceof the “fbus_p” type to an intermediate block (fbus_xchg) 101 having adifferent type of interface. Another intermediate block (fbus_xchg)(102), in FIGS. 8b and 8 c, connects the first intermediate block (101)to a bridge-type component (BRIDGE) of the DUT_CORE type thatcommunicates with a model, written primarily in an HDL-type language, ofa memory (MEMORY) of the DUT type, with a model written primarily in anHDL-type language of an input/output (I/O) of the DUT type, and with asystem block (SYS-BRIDGE).

[0084] The “Configurator” system of the invention handles the connectionof software simulation elements called components for the purpose ofsimulating hardware circuits.

[0085] There are at least 5 classes of components:

[0086] the “Active Components” (see below);

[0087] the “Monitoring and Verification Blocks” (see below);

[0088] the “Intermediate Blocks” (see below);

[0089] the “System Blocks” (see below);

[0090] the “Global Blocks: (see below and 1 of A2).

[0091] Each type of component can have several variants of embodiment ofthe same element, differentiated by the description level (see below) orby the signals in the interfaces (see below). Each type of Component canbe described in several levels of detail (functional, behavioral, gates,etc.), in an HDL-type language like VERILOG or VHDL, or in a high levellanguage (HLL) like C or C⁺⁺, complemented by an HDL-type interface.

[0092] Several description levels for describing similar functionalitiescan coexist and can have HDL-type interfaces that are similar but notnecessarily identical. Certain descriptions can have morefunctionalities, and the HDL-type interfaces can contain completelydifferent sets of signals.

[0093] The components are connected based on a predetermined schema thatis considered to be fixed for each execution of the Configurator system.These connections are defined by the architecture of the globalsimulation model and specified by the architecture description file(FDARCH) (see Annexes A1-A5).

[0094] Each instance of a component in this schema obtains a name orlabel that unambiguously identifies the position of the component andits type.

[0095] The definition file of the configuration (FCONF) provides asynthetic description of the Configuration variant to be generated bythe Configurator system. Only the main components (Active Components,Monitoring Blocks and Verification Blocks) are mentioned in it, alongwith the types of models desired. The other components (Global Blocks,System Blocks and Intermediate Blocks) are instantiated automatically bythe Configurator system.

[0096] Among the various types of components, the “Active Components”constitute the subset of the objects explicitly designated in theconfiguration file (FCONF) that exchange stimuli with their environmentby transmitting and receiving.

[0097] Among the various types of components, the “Monitoring andVerification Blocks” constitute the subset of the objects explicitlydesignated in the configuration file (FCONF) that merely receiveinformation from the environment. They are used for purposes ofobservation and Verification (MONITOR, VERIFIER). The operationgranularity of these models is the event, which reports changes incontrol signal values and arbitrary data exchanges.

[0098] All the other Components constitute so-called implicitcomponents, which are managed and instantiated automatically by theConfigurator system, as a function of the parameters of theconfiguration file (FCONF) (explicit component type, interface type,etc.).

[0099] The components can be connected to each other directly or viaexternal adaptation components called “Intermediate Blocks,” speciallydefined and declared for this purpose. They are often used, as will beseen below, during successive development phases to complete the missingparts of the design.

[0100] The Configurator system may thus insert one or more intermediateblocks to connect two active components.

[0101] The components called “System Blocks” are associated with theother components in order to supply them with the environment signalsthat are specific to them. These components encapsulate, at the level ofeach interface, all of the system signals that do not participate in theconnection between the other components. The “System Blocks” themselvesare connected to the “Global Blocks,” and manage all of the environmentsignals, i.e., the clock signals and general control signals (clock,reset, powergood, diagnostic), which may be transformed in order toadapt them to the needs of the corresponding active block (polaritychange, delay, etc.), as well as the specific signals that are differentfor each particular instance of the active component in question, forexample the signals that encode the module number or the operating modeof the component, etc. The latter are managed by parameters provided bythe Configurator system to the instances of the models of the componentsgenerated. If, for a given Component, the System Block is not necessary(which is indicated by the description tables of the configuration), itwill be connected directly to the Global Blocks (see 1 of A2).

[0102] The configuration file (FCONF) can contain additional informationspecifying intermediate blocks to be used in association with theinstances of the active components. Thus, the user can influence thechoice of the intermediate component, or eliminate the ambiguity ifthere are several possible choices. The connections thus obtained arecompared to the connection coherency rule table (TRCOH) in order todetect any incompatibilities between the ends of the connections betweenthe components, and in such a case to choose, and add into the instanceconnection table (TCINST), another adapter component (IntermediateBlock), inserted into the connection in question.

[0103] The Configurator system is based on a generic representation, asdescribed in FIGS. 3a through 3 c, common to all of the componentsdeclared in the architecture description file (FDARCH) of the globalsimulation model and comprising two parts, of the HDL type (for exampleVERILOG or VHDL) and HLL type (for example C⁺⁺).

[0104] In the case of a component described entirely in an HDL-typelanguage (FIG. 3a), the HLL-type part is reduced to one instance, whichmakes it possible to indicate its presence in the Configuration duringthe simulation and supplies the paths for access to the HDL-typeresources of the component.

[0105] For components described in an HLL-type language (FIG. 3c), it isthe HDL-type part that is reduced to a strict minimum and is limited tothe description of the interface registers and signals.

[0106] All of the intermediate levels between these two extremes arepossible, and are naturally used in the context of processes fordeveloping ASIC circuits.

[0107] Typically, during development, one begins with an HLL-type modelwith a minimal HDL-type interface, then moves on to increasinglycomplete HDL-type models written by the designers, and ends up withmodels on the logic gate level that are automatically synthesized fromHDL-type models.

[0108] Mixed models are often used because they allow for a precise andefficient simulation by dedicating the high-level language (HLL) tocomplex modelings for which the HLL-type language offers a compact andquickly executed solution. Nevertheless, even for models writtenprimarily in an HLL-type language, the HDL-type part can be non-trivialbecause of performance losses due to changes in the simulation contextbetween the HDL-type and HLL-type parts, respectively. A typical exampleis an interface whose signals change, even without any real datatransfer activity. In this case, it is preferable to process the signalsin the HDL-type part of the model, and to switch to the HLL-type partwhen the data are present in the interface.

[0109] The interface of a component is the set of all the signalspresent on its periphery. For components described in an HDL-typelanguage only, this corresponds to the external interface of thedefinition of this component in an HDL-type language (for exampleVERILOG or VHDL). For components defined in a mix of HLL- and HDL-typelanguages, the interface of a component is the sum of the signals of allthe HDL-type models used on the periphery of this component.

[0110]FIG. 4 describes the generic structure of the elementary modelsthat constitute the majority of the components. This structuretypically, though not exclusively, applies, in the case of the ASICcircuit under development, to interface adapters, intermediate blocks,and system blocks.

[0111] It includes a containing block, marked C, containing the HDL-typedescription marked A, and the HLL Block marked B that provide the pathsfor access to the HDL-type resources and, if necessary, a description ofthe block in an HLL-type language. The set of signals of the HDL-typeblock constitutes the interface of the block C. For purposes ofconnecting between the blocks, we will use the concept of Ports (seebelow), which are arbitrary logical selections of the signals of aninterface. It is possible for a signal to belong to several Ports atonce.

[0112] The Configurator system is capable of handling so-called“composite” models comprising a part in an HLL-type language andincluding other models of components called “interface adapters.”Interface adapters are mixed HDL/HLL-type models having a programinterface (API) in an HLL-type language through which they communicatewith the composite model. Composite models are particularly useful forsimulation environment components (for example MONITOR, VERIFIER,XACTORS) wherein the model must adapt to signals present in thedifferent variants of the models used in a configuration.

[0113]FIG. 5 describes the generic structure of composite models, usedespecially for modeling the components of the simulation environment.Seen from outside, the composite model is identical to the elementarymodel. Inside, the HLL specification of the model (marked D)communicates with the external HDL-type interface through interfaceadapters (marked C_Port_(i)), modeled by means of elementary structuresin an HLL-type language (marked B_PORT), and in an HDL-type language(marked A_PORT).

[0114] The Configurator system is equipped to automatically select theinterface adapters for a composite model. The Configurator systemexamines the list of usable interface adapters for a given compositemodel described by the properties of the model, and chooses theinterface adapter model whose physical connections with the rest of theglobal model conform to the connection coherency rule table (TRCOH).This approach makes it possible to quickly adapt to new types ofinterfaces by adding new adapters.

[0115] It is important to emphasize that the same component can bemodeled by either an elementary or a composite structure, depending onits description level.

[0116] An interface adapter component can be shared among severalcomposite models connected to the same port. Only one of these models isauthorized to transmit signals to the port, the other models beingpurely observers. A typical utilization involves the Monitoring andVerification Blocks, which do not send output signals. The sharing ofthe interface adapters speeds up the simulation by simplifying andfactoring parts of the model.

[0117] Hereinafter, the interface adapters that observe the signals onbehalf of the Monitoring or Verification Blocks that are CompositeModels will be called Probes.

[0118] The Configurator system is designed to optimize the utilizationof the Probes while keeping their numbers to a minimum. Since thedescription of the Components establishes the notion of equivalencybetween certain Components, the Configurator system first tries to sharethe port of an “Active Component.” If this proves impossible, itinstantiates a suitable Probe component that can be connected to theHDL-type interface from a list provided in the description of theMonitoring or Verification Component.

[0119] The section below explains the definitions related to theconnections between Components. The concepts of interfaces and ports areused to support the description of the connections between thecomponents.

[0120] Let us recall that the port is an arbitrary selection of signalsof the HDL-type interface of a component, performed using regularexpressions based on the names of these signals. A given signal canbelong to one or more ports. The definition of each port is constitutedby pairs of regular expressions and corresponding substituteexpressions. These expressions are successively applied to the name ofeach signal of the interface, and in case of an appropriate “match,” thesubstitute expression is applied, and the name thus obtained moves on tothe next substitution operation. If the final substitution gives a finalresult that is identical for two signals, the latter will be connectedto one another. The configurator generates a unique name for theconnection and places the appropriate information in the wiring table(TCAB). The method described makes it possible to express complexconnection rules between two components. For example, it is possible toconnect signals with different names, or to create rules for connectingthe input signals with the output signals.

[0121] The creation of this method for definition by the interfaces andthe ports makes it possible to separate the declarations of HDL-typemodels and the specifications of connections for the Configuratorsystem. The latter combines these two sources of information in order togenerate the connections. In the majority of cases, modifyingdeclarations in the HDL-type parts, which happens quite frequentlyduring development, does not entail any modifications in the regularexpressions that describe the wiring.

[0122] In the exemplary embodiment of the invention discussed below,only the point-to-point connections are described. The “bus”-typeconnections are easily modeled using a component with several outputsincorporating the bus.

[0123] The method of automatic connection between the “components” bythe Configurator system in order to create the global simulation modelwill be described below. This method comprises the following steps:

[0124] The reading of the architecture description file (FDARCH) of theglobal model and the storage, in a component and connection rule table,in a connection coherency rule table, and in a source file formattingtable, of information related to all of the possible configurations,each component obtaining a name that unambiguously identifies itsposition in the architecture, and a type from among several types(Active Components, Monitoring and Verification Blocks, IntermediateBlocks, System Blocks and Global Blocks).

[0125] The instantiation of the components specified in theconfiguration definition file by the user-developer using a list of thecomponents present, designated by their names and types and includingparameters or invoking procedures, the configuration definition filecomprising a file from which to select the components and their typesand optional additional indications concerning the type of interface andthe server involved in the configuration to be generated by theConfigurator, and the storage of the corresponding information in aninstance connection table.

[0126] The topological connection of the instances based on the schemadefined by the component and connection rule table (TCRC).

[0127] The reading and storage of the HDL-type sources of the modelsinstantiated, in order to extract the names and types of the interfacesignals from them.

[0128] The wiring of the interface signals, at the level of eachinstance of the components by applying regular expressions, stored inthe component and connection rule table (TCRC), based on the names ofthe signals constituting the wiring table (TCAB).

[0129] The use of the instance connection table (TCINST), the wiringtable (TCAB) and the formatting table (TFMT) to automatically generatethe HDL-type (MGHDL) and HLL-type (MGHLL) source files of the globalsimulation model corresponding to the configuration specified by theconfiguration definition file (FCONF).

[0130] The topological phase proceeds in the following way:

[0131] The explicit Components specified in the configuration file(FCONF) are first instantiated by the Configurator system and placed inthe instance connection table (TCINST). This table contains thedescription of each instance (label, type), accompanied by a list of thecomponents with which it is connected.

[0132] Next, the Intermediate Blocks, explicitly specified in the portsof the “Active Components” in the configuration file, are instantiatedand added to the instance connection table (TCINST).

[0133] The connections between the active components instantiated arecompared with the rules contained in the connection coherency table(TRCOH) in order to detect any incompatibilities between the ends of theconnections between the components, and in that case to choose, and addto the instance connection table (TCINST), an adapter component(Intermediate Block) to be inserted into the connection in question.

[0134] Next, the components of the Monitoring Block and VerificationBlock type are instantiated. The Configurator system analyzes theconnections of the composite model components and searches for sharableinterface adapters at the level of the common ports (see the modelsC_Port_(i) in FIG. 3). If there is no suitable component with which toshare the connection by observing the required signals, an interfaceadapter component with the properties specified by the description willbe instantiated by the configurator. The instance connection table(TCINST) is updated.

[0135] Lastly, the “system block” components are instantiated and placedin the instance connection table (TCINST) for the components that needthem.

[0136] In the Wiring phase, the Configurator system connects theinterface signals at the level of each port by applying regularexpressions based on the names of the signals as described in thedefinition of the port. These expressions are applied to the names ofthe signals extracted from the HDL-type descriptions of the components,so any changes in the HDL-type interfaces from one version of a model toanother do not directly affect the specifications of the connectionsbetween the blocks. This phase results in the generation of the wiringtable (TCAB), which associates the signals connected to one another withthe unique name of the wire that connects them. A certain number ofverifications are then possible, for example on the sourcelessconnections, or the connection of several outputs, or other connections.

[0137] The various steps in the wiring phase are the following:

[0138] The Global Components and System Blocks are first wired to all ofthe components.

[0139] Next, the signals between the other components are wired.

[0140] After the wiring, an additional pass makes it possible to connectthe signals of a component not connected in previous wiring phases tothe corresponding signals of the system block, specially provided forforcing known and stable values that inhibit the unused ports. Thesignals in question of the system blocks carry a special marking (forexample a special prefix in the name) so as not to be) connected duringthe previous wiring phases.

[0141] In a source file generation phase, the Configurator systemgenerates the HDL-type and HLL-type source files based on the content ofthe instance connection table (TCINST), the wiring table (TCAB) and theformatting table (TFMT), in order to automatically generate the HDL-type(MGHDL) and HLL-type (MGHLL) source files of the global simulation modelcorresponding to the configuration specified by the configuration file(FCONF).

[0142] The HDL-type source file contains a description of the HDL-typepart (for example in VERILOG) of the global simulation modelcorresponding to the configuration file (FCONF). In particular, itcontains the instantiation of all of the HDL-type models of thecomponents mentioned in the configuration file, the intermediate blocks,System Blocks and Global Blocks, as well as all of the wires connectingthese instances.

[0143] The HLL-type source file contains the program that corresponds tothe instantiation of all the components having part of their models inan HLL-type language. In the case of object-oriented HLL languages, thecode contains the constructors of HLL class objects with thecorresponding parameters specified in the description of each component.A formatting table (TFMT) specific to each design makes it possible togenerate the appropriate HLL-type code.

[0144] We will now describe the architecture description file (FDARCH)for a specific implementation of the configurator system (PROGCONF) inPERL language, chosen because of the direct manipulation of the regularexpressions and the associative tables on several levels.

[0145] The architecture, represented in FIG. 1, is constituted by aprocessor (CPU) communicating through a bridge (BRIDGE) with a systemmemory (MEMORY) and input/outputs (I/O).

[0146] In order to facilitate its writing and manipulation, the fileFDARCH represented has been divided into several parts, presented inAnnexes A1 through A5. This file defines the architecture of the globalsimulation model corresponding to the generic diagram represented inFIG. 1. The HDL-type language generated is VERWLOG and the high levellanguage (HLL) generated is C⁺⁺.

[0147] The properties of the Components (type, HDL-type interfaces,ports, constructors of objects of the C⁺⁺ class, etc.) are described inseveral tables written in PERL language. The correspondence betweenthese tables and the diagram illustrating the Configurator system ofFIG. 2 is represented in FIG. 6. In the description below, all of thenotations beginning with “% . . . ” correspond to hash tables. Thesetables can contain the description, either in the form of parameter setsor in the form of references to procedures that generate the requiredvalues.

[0148] The procedures are part of the description and are changed foreach design. The typical example of their utilization is the generationof interconnections between the components. Often, a table correspondingto all of the possible interconnections would be too large and difficultto generate and maintain. A procedure, on the other hand, can be verycompact.

[0149] The description of the rules for interconnecting the components(TCRC) contains global parameters common to all of the component types.It can exist in the form of at least one table. In the exemplaryembodiment of FIG. 6, it is shown in the form of seven associated (hash)tables, three of which have the entries (% InstNameModuleMap, %SysConnectMap, % SysSpecMap), the names designating all of the possiblemodels for the same component:

[0150] The table “% InstNameModuleMap” (see 2 of A1), which appears inthe file patent-config-defs.pm for describing the explicit Components.This table represents the rules for generating connections between thesignals. It has the entries Connect and SelfConnect.

[0151] The table “% SysConnectMap,” which appears in the filepatent_Sysconfig-defs.pm for the System Blocks.

[0152] The table “% SysSpecMap,” (see 4 of A2), which appears in thefile patent-Sysconfig-defs.pm for the Intermediate Blocks.

[0153] The two hash tables % SysWrapMap and % SysPinConst (see 6 of A2)contain the system level connection rules. The hash table %Activity-TypeMap associates the name of a component with its type. Thehash table % PortProbeMap has as entries the names of the HDL-typemodels used in the description of the components.

[0154] The Configurator system is controlled by at least one connectioncoherency rules table (TRCOH), which represents the rules forinterconnecting between the components and inserting intermediatecomponents. In the embodiment of FIG. 6, the connection coherency rulesare distributed in the form of the following two tables:

[0155] % HwfConnectivityMap (see. 2 of A2)

[0156] % HwifAlternateMap

[0157] The Configurator system is controlled by at least one source fileformatting table (TFMT), which represents the rules for generatinginstances of HLL-type objects. In the embodiment of FIG. 6, the rulesfor generating instances of HLL-type objects are distributed in the formof the following two tables:

[0158] % moduleToCppClassMap (see 1 of A5)

[0159] % classCppProtoMap (see. 2 of A5)

[0160] The role of each of these hash tables is described in detailbelow.

[0161] Among the entries defined for the tables % InstNameModuleMap, %SysConnectMap, % SysSpecMap, certain are mandatory:

[0162] The entry “MatchExpr,” whose value is the regular expression thatmakes it possible to accept a name (label) of the component in theconfiguration file, is used to define the variants of the positionsauthorized for the component.

[0163] The entry “ExtrExpr,” whose value is the regular expression thatperforms the extraction of the digital parameters from the name (label),is used for the instantiation of the Intermediate Blocks or the SystemBlocks or for generating the label of the implicit component.

[0164] Other parameters are optional and can be added to the descriptionof the tables, but these parameters can only be used by the codeprovided with the description; among them:

[0165] NumAdd is an auxiliary parameter serving as a modifier for theparameters extracted by ExtrExpr, used by the procedure GenDest (seebelow).

[0166] BaseldExpr is a regular expression that makes it possible to findthe active component corresponding to an intermediate or systemcomponent in case of ambiguity.

[0167] The following hash entries define the Type of the component, forexample DUT (HDL-type model), XACTOR (transactor) or other types.

[0168] Each Component Type corresponds to a hash, in turn composed ofthe following entries:

[0169] The entry ReqModule contains the name of the HDL-type (VERILOG)module of the component and the name of the corresponding source file,

[0170] The entry “Connect” is the definition of the method for selectingthe signals that are part of a Port. This description is composed of aset of entries indexed by the name of the Port. Each Port name isassociated with a table of regular expressions and a pointer to aprocedure for connecting the signals, which controls the application ofthese expression to the names of the signals of the interface of thecomponent.

[0171] The Configurator has several preprogrammed procedures, but otherscan be added and referenced. The preprogrammed procedures accept themodifiers:

[0172] E (exclusive—the signal will be used only once).

[0173] T (branch—the signal can be used by several destinations).

[0174] A special value “filter-out_wire_name” assigned to a signal or agroup of signals makes it possible to eliminate any connection to thecorresponding signals.

[0175] The entry “SelfConnect”—similar to the entry “Connect”—containsthe definitions of the connections of the Port signals that can beconnected between two instances of the same component. This definitionfacilitates the connection of one-way output ? input signals in theparticular case of a head-to-tail connection.

[0176] The entry “Port” provides the definition of all of the ports. Itis a hash that associates the name of each port with a table thatincludes the following elements:

[0177] The logical name of the HDL-type component.

[0178] The name of the HDL-type module or a choice of modules.

[0179] The number of the port (useful for generating VERILOG and C⁺⁺code).

[0180] The entry “GenDest (see 1 of A3) is a pointer to the procedurethat, for a component designated by a label and type, generates, foreach port, the label of the component to which it is connected. Thereferenced procedure must imperatively be specified by the user; thisprocedure is also used to control the coherency of the requestedconfiguration.

[0181] The entry “SysConn” is a hash that associates each HDL-typemodule contained in the model with a pointer to the procedure forselecting and naming the System Blocks. The referenced procedure mustimperatively be specified by the user.

[0182] The entry “GenHDLlnstParam” is a pointer to the procedure thatgenerates the additional parameters required by the HDL-type simulatorfor the code generated, which instantiates the HDL-type part of thecomponent.

[0183] The entry “CfgCpp” defines the parameters of the constructor ofthe object for the C⁺⁺ identification code of the Configuration,generated automatically, which serves as a filter for the selection ofthe Components by the Configurator system.

[0184] The first parameter is the name of the class of the C⁺⁺ object;it is a predefined name associated with that of the HLD-type model. Itis followed by the tables that correspond to groups of parameterstypically associated with each port of the component. The keyword “Own”indicates an elementary model component.

[0185] Next comes the name of the HDL-type component referenced in thePort part and the type identifier of the component, for example DUT,model of the circuit under design, XACTOR, or transactor.

[0186] For the composite model blocks, the parameter part is richer.

[0187] It contains the keyword “Src” for the active components or “Mon”for the Verification and Monitoring components.

[0188] Next come the parameters of the interface adapter component,comprising:

[0189] the name of the HDL-type component.

[0190] the identifier of the component type and its class followed bythe name of the corresponding port.

[0191] The latter parameters are specific to each port of the compositeblock.

[0192] In the C⁺⁺ code generated for a composite model, the parameterstransmitted to the constructor of a class correspond to the pointers tothe instances of the interface adapters.

[0193] All of these parameters serve to guide the generator of the C++code, which combines them with the rules contained in the hash table “%classCppProtoMap”:

[0194] The entry “ProbeConnect” associates each port of a Monitor orVerifier component with the C++ class that is acceptable as an interfaceadapter. Thus, the Configurator is capable of optimizing the code byusing the same interface adapter for several components (compositemodel).

[0195] The entry “SysWrap” is a hash that, for each HDL-type part of acomponent, defines the regular expression to be used for setting theremaining unconnected signals to a known state after the wiring betweenthe components.

[0196] The algorithm for connecting two components is the following:

[0197] The Configurator system first tries direct connection.

[0198] If this proves impossible based on the first hash table %HwfConnectivityMap, the modules specified in % HwifAlternateMap areretrieved in order to be placed in the component. The optional modulesare indicated by the character “>” at the beginning of their name in thespecification of a component.

[0199] In the end, if no module works, the Configurator system returnsto the hash % HwfConnectivityMap to choose the intermediate blocks to beplaced between the components.

[0200] If no suitable block is found, an error is signaled.

[0201] The user can influence the Configurator system's choice byexplicitly specifying in the configuration file the intermediate blocksto be connected to a component.

[0202] The table “% HwfConnectivityMap” allows for both the Verificationof connectivity and the specification of intermediate Blocks to beinserted in order to connect two Components whose parts are not directlyconnectable.

[0203] In order for two blocks to be able to be connected to each other,it is necessary for % HwfConnectivityMap to contain entries thatdescribe the properties of this connection.

[0204] Each component is associated with the component, to which it canbe connected.

[0205] A direct connection is indicated by the value “Direct.”

[0206] For connections requiring an intermediate Block, the name of thisblock is indicated.

[0207] For certain blocks, the connectivity can be specified differentlyfor each port of the block. This serves to eliminate the ambiguity inthe connections of a block. A typical utilization involves the insertionof two intermediate blocks connected head-to-tail between two explicitcomponents.

[0208] It is emphasized that the connectivity in this case is expressedglobally, without specifying the names of signals to be connected.

[0209] The Components described in an HLL-type language can have severalpossible implementations of the HDL-type modules A-Port, at the level ofeach port i (see FIG. 3). The hash table “% HwifAlternateMap” specifiesthe choice that is possible for each HDL-type module of a component. Theconfigurator system uses this information in order to insert theintermediate blocks only when strictly necessary.

[0210] The hash % SysWrapMap defines, for each implementation of acomponent, its System Block. The entries are names of HDL-type modulesassociated with the name of the system block and its HDL-typeimplementation. This information is used by the Configurator system toinstantiate the appropriate system block from specifications containedin the hash % SysConnectMap (see 3 of A2).

[0211] The hash % SysPinConst associates, with each System Block, theconnections of certain signals of its interface to the names of thecorresponding signals (wires) at the system level. These connections areindependent of the configurations and are not governed by the regularexpressions that are applicable during the wiring of the other signals.

[0212] Typically, the signals in question are clock signals, resetsignals, etc. The referenced names are declared in an HDL-type code thatis specific for each model under design, and are provided by the user(in the form of a variable or a file) with the descriptions of thecomponents and the specific connection rules.

[0213] This specific HDL-type code is systematically included at thebeginning of the HDL-type code generated by the Configurator system.

[0214] The procedure “&gen_sys_VlogInstParameter” is a procedure thatgenerates the instantiation parameters for the generator of the HDL-typecode from the label and of the type of each Component.

[0215] The hash % Activity-TypeMap (see 1 of A1) associates the name ofa component with its type, specified by a keyword:

[0216] “actor” for the active components.

[0217] “spectator” for the Monitoring blocks.

[0218] “checker” for the Verification blocks.

[0219] “helper” for the System blocks or the Intermediate blocks in caseof an indirect connection.

[0220] The table “% PortProbeMap” is a hash whose entries are the namesof the HDL-type models used in the description of the components. Thevalues are in turn hashes that associate, with each port name, a tablecontaining the name of a block that can serve as a Probe for observingthe signals of this port and the name of the corresponding C⁺⁺ class.This hash informs the Configurator system of the type of componentcapable of observing the signals of a given port and the type of C⁺⁺ APIthat can be used to analyze the control and data flow observed in thisport.

[0221] The procedure &GenDest accepts as input the label of the sourcecomponent, its type and its port. The result returned is a hash thatassociates the label of the connected target component with its port.

[0222] In order to control the coherency of the configuration generatedno matter what the order in which the Components are handled, theConfigurator system calls the procedure &GenDest with the parametersobtained for the target component used as a source and verifies that theresult actually corresponds to the initial source component and port.

[0223] The Configurator system calls the procedure &GenDest for eachcomponent contained in the configuration file, running through all ofthese ports.

[0224] The hash returned by &GenDest can contain several components withtheir respective ports. This is particularly the case for connections ofthe “bus” type; &GenDest returns all of the components connected by thebusses except the one that is given as an argument. The Configuratorsystem automatically inserts the necessary “bus” component.

[0225] The hash &moduleToCppClassMap is a search accelerator that makesit possible to retrieve the C⁺⁺ class from the name of the HDL-typemodule; it only applies to elementary Models (see 1.14).

[0226] The hash % classCppProtoMap describes the generation of theconstructors of C⁺⁺ class objects. Each entry corresponds to the name ofa C⁺⁺ class. Each description is a hash composed of four entries:

[0227] The entry “Prea” corresponds to the generation of the first partof the constructor (class, name of the instance, first parameters).

[0228] The entry “Iter” corresponds to the iterative part of theparameters of the constructor. This rule is applied for each elementcontained in the entry CfgCpp of the description of the component.

[0229] The entry “Post” corresponds to the last part of the constructor(last parameters, closing parentheses).

[0230] The entry “Idle” is a rule that substitutes for the rule “Iter”for nonexistent connections (partial configurations). Typically, a nullpointer or null string is generated.

[0231] Each entry is a character string containing predetermined specialselectors, replaced by the values calculated by the Configurator system.These selectors have the general form #<Src:Dst:Act><Item#, where “Src,”“Dst” and “Act” indicate the instance to be used, the latter beingtransmitted as a parameter to a constructor of an HLL object.

[0232] “Src” indicates the current instance.

[0233] “Dst” indicates the instance connected to the other end of theport.

[0234] “Act:” indicates the composite instance corresponding to theActive Component containing the observation port.

[0235] <Item>is a keyword indicating the selection:

[0236] “Inst” for the instance name cpp.

[0237] “Iid” for the component label corresponding to Inst.

[0238] “Ict” for the component type (DUT, VERIFIER, XACTOR, Monitor,etc.).

[0239] “Port” for the name of the port.

[0240] The two variables “$cpp_preamble” (see 3ofn A5) and“$cpp_postamble” (see 4 of A5) respectively contain the beginning andthe end of the C⁺⁺ program text generated by the Configurator system.The text generated from the table % classCppProtoMap is inserted in themiddle.

[0241] The two variables “$top_verilog_preamble” and“$top_verilog_postamble” respectively contain the beginning and the endof the text of the instance “top” of the HDL-type (VERILOG) descriptionof the configuration. Typically, they are the instantiations of clockblocks and other system level blocks.

[0242] The description that follows is a simple example of thegeneration of a Configuration through the implementation of theConfigurator system, which is illustrated in a simplified case based onthe architecture of a System constituted by a bridge (BRIDGE) thatconnects a central processor (CPU), a Memory, and an input/output card(I/O). The Architecture of the System is represented in FIG. 1.

[0243] In this example, the CPU and the BRIDGE can be modeled, either bya VERILOG model of the design (DUT, DUT_Core), or by a C⁺⁺ compositemodel (XACTOR).

[0244] The interface between the CPU and the BRIDGE is called FBUS.Several variants of this interface are considered to correspond tosuccessive stages of development.

[0245] The global block Clock handles the distribution of the clocksignals and system signals globally for all of the Components.

[0246] The Configurator system relies on the description of the HDL-typeInterfaces of the Components. Simple interfaces, written in VERILOGlanguage, are proposed below as examples for each of the Components. TheConfigurator system analyzes only this part of the source filescontained in the library of HDL-type source files (BFSHDL). They belongto a methodology for progressively handling variants of models as theybecome available.

[0247] The following HDL-type description of the Interfaces has beenreduced to only what is necessary to illustrate the capabilities and theoperation of the configurator. In a real situation, the behavioraldescriptions are included, as in the case of the model of the clock (themodule CLOCK).

[0248] The description is as follows:

[0249] CPU:

[0250] a) The model DUT of the component CPU (FIG. 7a) has a port FBUSfor connecting with the BRIDGE, as well as a set of System signals,defined below. module cpu ( XXadr_dat, XXreq, XXack, // clk, reset,powergood ); inout [63:0] XXadr_dat; inout [3:0] XXreq; inout [3:0]XXack; input clk; input reset; input powergood; endmodule

[0251] b) The model XACTOR (FIG. 7b) consists in an abstract C⁺⁺ modelwhose HDL-type instance is constituted by that of the Port named fbus_p.In this example, it is assumed that the Port FBUS has a variant namedFBUSA wherein the two-way signals adr_dat have been separated into pairsof one-way in (inXXadr_dat) and out (outXXadr_dat) signals. modulefbus_p ( inXXadr_dat, outXXadr_dat, inXXreq, outXXreq, inXXack,outXXack, // clk, reset, powergood ); input [63:0] inXXadr_dat; output[63:0] outXXadr_dat; input [3:0] inXXreq; output [3:0] outXXreq; input[3:0] inXXack; output [3:0] outXXack; input clk; input reset; inputpowergood; endmodule

[0252] c) The model MONITOR of the component CPU is a composite modelthat allows the Monitoring of the interface FBUS. In the case wherethere is no port adapter fbus_p in the configuration, a probe containingthe instance fbus_probe will be generated (FIG. 7c). module fbus_probe (XXadr_dat, XXreq, XXack // clk, reset, powergood ); input [63:0]XXadr_dat; input [3:0] XXreq; input [3:0] XXack; input clk; input reset;input powergood; endmodule

[0253] Intermediate adaptation blocks FBUS:

[0254] These blocks implement the interface adaptation at the FBUS levelin the case where point-to-point mapping of the signals is impossible.The port FBUSA is the variant of FBUS in which the two-way signals havebeen separated into pairs of one-way incoming (in) and outgoing (out)signals.

[0255] The model fbus_xchg (FIG. 7d) implements the adaptation betweenthe interface FBUS of the port fbus_p and that of a port FBUSA; thewidth of the interface can be parameterized so as to accommodatepotential technological evolutions. module fbus_xchg ( XXadr_dat, XXreq,XXack, // inXXadr_dat, outXXadr_dat, inXXreq, outXXreq, inXXack,outXXack, ); inout [63:0] XXadr_dat; inout [3:0] XXreq; inout [3:0]XXack; // input [63:0] inXXadr_dat; output [63:0] outXXadr_dat; input[3:0] inXXreq; output [3:0] outXXreq; input [3:0] inXXack; output [3:0]outXXack; // model body endmodule BRIDGE:

[0256] a) The model DUT of the component BRIDGE (FIG. 7e) has the threerespective ports to the models CPU, MEM and 10 as well as the Systemsignals delivered by the dedicated system block SYS_BRIDGE and by theglobal block CLOCK. module bridge ( XXadr_dat, XXreq, XXack, YYadr,YYdata, ZZdata, ZZreq, ZZack, YYctrl, clk_2xp, clk_2xn, clkp, clkn,reset, powergood ); inout [63:0] XXadr_dat; inout [3:0] XXack; inout[3:0] XXreq; output [31:0] YYadr; inout [63:0] YYdata; output [2:0]YYctrl; inout [15:0] ZZdata; input [1:0] ZZack; output [1:0] ZZreq;input clk_2xp; input clk_2xn; input clkp; input clkn; input reset; inputpowergood; endmodule

[0257] b) The model BRIDGE_CORE (FIG. 7f) is the variant DUT_CORE of thecomponent BRIDGE having an interface FBUSA. This model reflects thesituation in which the model of the FBUS interface controller is notavailable. module bridge_core ( inXXadr_dat, outXXadr_dat, inXXreq,outXXreq, inXXack, outXXack, // YYadr, YYdata, YYctrl, // ZZdata, ZZreq,ZZack, // clk_2xp, clk_2xn, clkp, clkn, reset, powergood ); input [63:0]inXXadr_dat; output [63:0] outXXadr_dat; input [3:0] inXXreq; output[3:0] outXXreq; input [3:0] inXXack; output [3:0] outXXack; output[31:0] YYadr; inout [63:0] YYdata; output [2:0] YYctrl; inout [15:0]ZZdata; input [1:0] ZZack; output [1:0] ZZreq; input clk_2xp; inputclk_2xn; input clkp; input clkn; YYadr, YYdata, YYctrl, clk, reset,powergood ); output [31:0] YYadr; inout [63:0] YYdata; output [2:0]YYctrl; input clk; input reset; input powergood; endmodule module cio_p( ZZdata, ZZreq, ZZack, // clk, reset, powergood ); inout [15:0] ZZdata;input [1:0] ZZack; output [1:0] ZZreq; input clk; input reset; inputpowergood; endmodule MEMORY:

[0258] The model DUT of the component MEMORY (FIG. 7i) has therespective ports to the models BRIDGE and CLOCK. model DUT: module cmem( YYadr, YYdata, YYctrl, clk, reset, powergood ); input [31:0] YYadr;inout [63:0] YYdata; input [2:0] YYctrl; input clk; input reset; inputpowergood; endmodule I/O:

[0259] The model DUT of the component I/O (FIG. 7j) has the respectiveports to the models BRIDGE and CLOCK. model DUT: module cio ( ZZdata,ZZreq, ZZack, clk, reset, powergood ); inout [15:0] ZZdata; output [1:0]ZZack; input [1:0] ZZreq; input clk; input reset; input powergood;endmodule Global System Block:

[0260] This model (FIG. 7k) handles the delivery of the System signalsthat feed the system blocks dedicated to each component. module Clock (sys_POWER_GOOD, sys_RESET, sys_CLK, sys_CLK_2X ); output sys_POWER_GOOD;output sys_RESET; output sys_CLK; output sys_CLK_2X; parameterHALF_PERIOD = 75; // 7.5ns, 66MHz parameter RESET_DELAY = 10000000000 ;// 1.0ms parameter POWER_GOOD_DELAY = 5000000000 ; // 0.5ms initialbegin; sys_POWER_GOOD = 0; sys_RESET = 0; sys_CLK = 0; sys_CLK_2X = 0;#POWER_GOOD_DELAY sys_POWER_GOOD = 1; #RESET_DELAY sys_RESET = 1; endalways begin #HALF_PERIOD sys_CLK = ˜sys_CLK; end always @(posedgesys_CLK_2X) begin sys_CLK = ˜sys_CLK; end endmodule

[0261] Definition of the configurations:

[0262] The configuration variants mark the various verification stagesbased on the availability of the models; the Configurator systemgenerates the configurations unambiguously from topological informationcontained in the configuration file.

[0263] The first configuration is defined by the configuration file 1below, represented in FIG. 8a; the models DUT of the CPU and the BRIDGEare not available.

[0264] Configuration file 1:

[0265] CPU_(—)0XACTOR

[0266] CPU_(—)0MONITOR

[0267] BRIDGE_(—)0 XACTOR

[0268] CMEM_(—)0 DUT

[0269] CIO_(—)0 DUT

[0270] The XACTOR CPU shares the port fbus_p with the MONITOR.

[0271] The second configuration is defined by the configuration file 2below, represented in FIG. 8b.

[0272] The BRIDGE XACTOR is connected to the CPU XACTOR by an FBUSA-typeinterface specified in the configuration file by the attributeFBUSA=FBUS_xchg; the Configurator system automatically inserts thesecond adapter fbus_xchg 102.

[0273] Configuration file 2: CPU_0 XACTOR FBUSA = FBUS_xchg CPU_0MONITOR BRIDGE_0 XACTOR CMEM_0 DUT CIO_0 DUT

[0274] The XACTOR CPU shares the port fbus_p with the Monitor.

[0275] The third configuration is defined by the configuration file 3below, represented in FIG. 8c; the BRIDGE DUT_CORE is connected to theCPU XACTOR by an FBUSA-type interface specified in the configurationfile by the attribute FBUSA=FBUS_xchg; the Configurator systemautomatically inserts the second adapter fbus_xchg 102.

[0276] Configuration file 3: CPU_0 XACTOR FBUSA = FBUS_xchg CPU_0MONITOR BRIDGE_0 DUT_CORE CMEM_0 DUT CIO_0 DUT

[0277] The XACTOR CPU shares the port fbus_p with the MONITOR.

[0278] The fourth configuration is defined by the configuration file 4below, represented in FIG. 8d; the model CPU DUT is connected to themodel BRIDGE XACTOR. The Configurator system automatically inserts aninterface adapter fbus for implementing the connection between the CPUDUT and the BRIDGE XAXTOR without any explicit mention of this block inthe configuration file.

[0279] Configuration file 4: CPU_0 DUT CPU_0 MONITOR BRIDGE_0 XACTORCMEM_0 DUT CIO_0 DUT

[0280] The Configurator automatically instantiates the Probe fbus_probein order to allow the observation of the interface FBUS by the Monitor.

[0281] The fifth configuration is defined by the configuration file 5below, represented in FIG. 8e; all of the models DUT are available.

[0282] Configuration file 5: CPU_0 DUT CPU_0 MONITOR BRIDGE_0 DUT CMEM_0DUT CIO_0 DUT

[0283] The Configurator system automatically instantiates the Probefbus_probe in order to allow the observation of the interface FBUS bythe Monitor.

[0284] The sixth configuration is defined by the configuration file 6below, represented in FIG. 8f; it is a multi-server Configuration;Config1 is distributed between the 2 servers SERVER1 and SERVER2, thecutoff occurring at the level of the interface FBUS.

[0285] Configuration file 6: CPU_0 XACTOR SERVER1 CPU_0 MONITOR SERVER1BRIDGE_0 XACTOR SERVER2 CMEM_0 DUT SERVER2 CIO_0 DUT SERVER2

[0286] The connectivity rules that make it possible to generate theconnectivity tables of any configuration for this example are describedin PERL language in Annexes A1 through A5.

[0287] Annex A1 describes, in the case of the example chosen, thetopological rules linked to the active components to be used by theConfigurator system.

[0288] Annex A2 describes the topological rules linked to the systemBlocks and the Intermediate blocks to be used by the Configuratorsystem.

[0289] Annex A3 describes the procedures for connecting the Componentsto be used by the Configurator system.

[0290] Annex A4 describes the code for generating the file in HDL-typelanguage (Verilog_top.v) for connecting the components to be used by theConfigurator system.

[0291] Annex A5 describes the code for generating C⁺⁺ Classes.

[0292] Annexes A6 and A7 describe the result files generated by theConfigurator system, respectively in a low level HDL-type language(VERILOG) and in a high level language (C⁺⁺), in order to create themodel of the configuration defined by the third configurationcorresponding to FIG. 8c. The configurator can thus, with theuser-developer, create its own model in accordance with theconfiguration variant chosen.

[0293] It would have been possible, in the same way, to illustrate theother variants of embodiment of the model (FIGS. 8a; 8 b and 8 d through8 f) that could be processed by the Configurator system in order toproduce the corresponding result files constituting the simulationmodels of the system architecture envisioned for the integrated circuitunder development.

[0294]FIG. 2 represents the various means used by a computer system 40implementing the method of the invention.

[0295] The computer 40 includes a central processor 41 comprising dataprocessing circuits 42 (an arithmetic and logic unit ALU and memories ofassociated programs, hereinafter referred to globally as ALU, forconvenience), and includes various memories, programs or working datafiles associated with the central processor 41.

[0296] The central processor 41 includes a memory 51 containing thecomponent and connection rule table (TCRC), the connection coherencyrule table (TRCOH) and the source file formatting table (TFMT). Thesetables are created from the architecture description file (FDARCH).

[0297] The memory 51 also contains the necessary programs or intelligentengines PROGCONF for constituting the Configurator system, which areusable by the ALU 42.

[0298] A memory 53 contains the instance connection table (TCINST)representing the instances of the components and their mutualinterconnections required by the Configuration defined in theconfiguration file FCONF and conforming to the rules contained in thetables TCRC and TRCOH.

[0299] The memory 53 also contains the wiring table (TCAB) representingthe physical connections (wires) between the HDL-type parts of thecomponents instantiated from the HDL-type source file library (BFSHDL).

[0300] This results in the files MGHDL and MGHLL, which respectivelyrepresent the HDL-type (VERILOG or VHDL) and HLL-type (C⁺⁺) source filesof the global simulation model generated by the Configurator system, amodel that allows the co-simulation of an ASIC circuit in itsverification environment.

[0301] The implementation of the method of the invention will now beexplained.

[0302] The method for automatically generating, by means of the computeror data processing system 40, a simulation model of a configuration ofmodels of given components, mutually linked by interworking connectionsso as to create a global simulation model MGHDL/MGHLL of an ASIC circuitin its verification environment, includes the following steps (see FIG.2a):

[0303] an operator, possibly aided or even replaced by a computer,generates the architecture description file (FDARCH) describing therules for interconnection between the various components, the modelsbeing capable of being used to model each of these components and theformatting rules in order to generate the source files of the resultingmodel.

[0304] an operator, possibly aided or even replaced by a computer,generates the source file library BFSHDL from HDL-type parts of modelsof respective components capable of being used in a configuration inconformity with the content of the file FDARCH.

[0305] the operator generates the desired configuration file FCONF,which identifies the components and the desired models (see FIG. 2b).

[0306] The data processing system reads the architecture descriptionfile (FDARCH) and generates and places in memory the tables TCRC, TRCOHand TFMT from FDARCH (see FIG. 2b).

[0307] The various tables TCRC, TRCOH and TFMT having been madeaccessible to the data processing system 40 (see FIG. 2c),

[0308] the data processing system 40 reads the desired configurationfile FCONF in order to identify the components and their required models(see FIG. 2c);

[0309] it reads the component and connection rule table in order toinstantiate the required components and place them in the instanceconnection table TCINST (see FIG. 2c).

[0310] It reads the connection coherency rule table (TRCOH) in order toverify the physical connectivity between models and, if necessary,inserts intermediate components.

[0311] It reads, in the library BFSHDL, the source files correspondingto the HDL-type parts of the component models instantiated in the tableTCINST in order to generate the table TCAB of physical connections(wires) between the component models (see FIG. 2c).

[0312] It applies the formatting rules from the table TFMT to thecontents of the tables TCINST and TCAB, and it generates the finalsource files MGHDLUMGHLL of the global simulation model corresponding tothe configuration specified by the configuration file (FCONF) (see FIG.2d).

[0313] The input file FCONC corresponds to a description of thetheoretical diagram of the type in FIG. 1, but without the models, whichare added during the generation of the intermediate tables TCINST, TCABdescribing the configuration and connections, in order to provide aglobal simulation model that is actually operational and that, moreover,allows the observation of particular signals.

[0314] The various tables above can be pre-stored in the computer 40 orcan even be stored in an external memory that one connects to thecomputer 40, possibly through a data transmission network, in order tomake them accessible.

[0315] The ALU 42 has all of the basic data required by the table toolsTCRC, TRCOH, TFMT in order for the program PROGCONF associated with theConfigurator system to control, in the ALU 42, the generation of thefinal files MGHDL/MGHLL (see FIG. 2d).

[0316] The intermediate table TCAB describing the physical connectionsgenerated from an HDL_type description, is, in this example, subjectedto a verification in order to detect any obvious errors, such as theexistence of unconnected inputs or outputs or even outputs connected inparallel, when there should be conventional outputs of the so-called“totem-pole” type, as opposed to those of the open collector ortri-state type.

[0317] In case of a modification of the initial file FCONF, theintermediate tables TCINST, TCAB and the final files MGHDL/MGHLL canthus be redefined from the files of models and from the file FDARCH.This avoids any risk of error.

[0318] In this example, the ALU 42 generates a global co-simulationmodel by associating, with at least one functional block, severalfunctional specification models written in programming languages ofdifferent levels, in this case of the HDL and C⁺⁺ types.

[0319] It is understood that the present invention can be implemented inother specific forms without going beyond its scope of application asclaimed. Consequently, the present detailed description should beconsidered to be a simple illustration of a particular case within thecontext of the invention, and can therefore be modified without goingbeyond the scope defined by the attached claims.

1. Method of automatic generation, by means of a data processing system(40) associated with a program called a Configurator for creating aglobal simulation model of an architecture comprising models ofintegrated circuits under development that can constitute, with the helpof the automatic Configurator, a machine or a part of a machine, andenvironment simulation models that make it possible to test and verifythe circuit under development, a configuration definition file (FCONF)for components of the architecture, these components constituting fixedfunctional blocks for describing the functionalities of integratedcircuits or parts of integrated circuits, the components being chosen bythe user from a library of various component types and a library ofenvironment components, in order to create the global model of thearchitecture corresponding to the functional specification defined inthe configuration definition file (FCONF) and conforming to thespecification of the architecture of the global model specified by anarchitecture description file (FDARCH), a method characterized in thatit includes the following steps: the reading of the architecturedescription file (FDARCH) of the global model and the storage, in acomponent and connection rule table (TCRC), in a connection coherencyrule table (TRCOH), and in a source file formatting table (TMFT), ofinformation related to all of the possible configurations, eachcomponent obtaining a name (LABEL) that unambiguously identifies itsposition in the architecture, and a type from among several types(Active Components, Monitoring and Verification Blocks, IntermediateBlocks, System Blocks and Global Blocks), the instantiation of thecomponents specified in the configuration definition file (FCONF) by theuser-developer using a list of the components preset, designated bytheir names and types and including parameters or invoking procedures,the configuration definition file (FCONF) comprising a file from whichto select the components and their types and optional additionalindications concerning the type of interface and the server involved inthe configuration to be generated by the Configurator, and the storageof the corresponding information in an instance connection table(TCIST), the topological connection of the instances and the storage ofthe corresponding information in an instance connection table (TCINST),the physical connection of the interface signals, at the level of eachinstance of the components, by applying regular expressions, stored inthe component and connection rule table (TCRC), based on the names ofthe signals constituting a wiring table (TCAB), the use of the instanceconnection table (TCINST), the wiring table (TCAB) and the formattingtable (TFMT) to automatically generate HDL-type (MGHDL) and HLL-type(MGHLL) source files of the global simulation model corresponding to theconfiguration specified by the configuration definition file (FCONF). 2.Method according to claim 1, wherein the Configurator system transmitsto the HLL-type parts of each component information on: the name (LABEL)of the component; the type of the instance (DUT, XACTOR, VERIFIER,MONITOR), the HDL path, i.e. the hierarchical name of the component inthe description of the model.
 3. Method according to claim 1 or 2,wherein the configuration definition file (FCONF) also includes akeyword (server<n>) indicating the name or number of the server in whicha component is instantiated when the method is used in a multi-serversystem.
 4. Method according to claim 4 wherein, in the case of amulti-server utilization, the configurator system executes the followingsteps: the division of the Configuration into several (HDL type and HLLtype) parts, sorting the HDL-type components and the HLL objectsaccording to the servers to which they belong, the generation of theHDL-type peripheral components used for sending and receiving signalsbetween the parts of the configuration, the duplication of the GlobalBlocks by the Configurator system and the instantiation of the GlobalBlocks duplicated in each server, the generation of the HLL-type partsthat serve as a communication medium between the servers.
 5. Methodaccording to claim 3 or 4, wherein the automatic connection between thecomponents by the Configurator system includes several phases: ahigh-level topological phase for selecting the components and theirrespective positions, a wiring phase for creating the actual connectionbetween the components, this phase generating as a result a wiring table(TCAB) that associates the signals connected to one another with theunique name of the wire that connects them, a phase for generatingHDL-type and HLL-type source files.
 6. Method according to claim 5,wherein the wiring phase is performed by the Configurator system in thefollowing three steps: a. the Global Blocks and the System Blocks arefirst connected to all of he components, b. next come the connections ofthe signals between the other components, c. after the wiring, anadditional pass makes it possible to connect the remaining unconnectedsignals of each component to predetermined signals in order to produce agiven stable state; the Configurator system then generates partialconfigurations comprising a subset of the architecture.
 7. Methodaccording to claim 6, wherein the predetermined signals are the signalsof the System Block corresponding to the component.
 8. Method accordingto any of claims 1 through 7, wherein the description file of thearchitecture (FDARCH) of the global model includes the simulation modelsof the Global Blocks and the System Blocks, these two types ofcomponents being connected to one another and handling environmentsignals.
 9. Method according to claim 8, wherein the System Blocks areconnected to the other components and supply them with the systemsignals that are specific to them
 10. Method according to claim 9,wherein the data processing system (40) performs a conformity check ofthe connections, comparing the connection table of the real instancesbetween blocks (TCINST) to the connection coherency rule table (TRCOH).11. Method according to claim 10, wherein the data processing system(40) compares the physical connections between the components to theconnection coherency rule table (TRCOH), in order to detect anyincompatibilities between the ends of the connections between thecomponents, and in such a case, it specifies, and adds into the instanceconnection table (TCINST), an adapter component (Intermediate Block)(101) inserted into the connection in question.
 12. Method according toclaim 11, wherein the configuration definition file (FCONF) includesinformation, specified by an attribute, concerning the utilization ofadapter components (Intermediate Blocks) with the instances of theactive Components, whose connections are compared to the instanceconnection table (TCINST), in order to detect any incompatibilitiesbetween the ends of the connections between the components, and in sucha case it specifies, and adds into the instance connection table(TCINST), another adapter component (Intermediate Block) (102) insertedinto the connection in question.
 13. Method according to claim 12,wherein the data processing system (40) selects certain connectionsbetween the components of the connection coherency rule table (TRCOH)and specifies, and adds into the instance connection table (TCINST),additional connections constituting branches leading to respectiveadditional models, which represent tools (probes) for monitoring theconnections.
 14. Method according to any of claims 1 through 13 wherein,in the source file generation nphase, the Configurator system generatesthe source files in HDL language (MGHDL) and in HLL language (MGHLL),based on the content of the component and connection rule table (TCRC),the coherency rule table (TRCOH), the source file formatting table(TMFT), the instance connection table (TCINST) and the wiring table(TCAB).
 15. Method according to claim 14, wherein the data processingsystem (40) executes an operation through the Configurator system foreach configuration variant, in order to obtain several simulation modelscorresponding to the same functional specification, but written in adescription comprising various mixtures of languages of different levels(HDL, HLL).
 16. Method according to any of claims 1 through 15, whereinthe data processing system (40) generates the functional specificationof the global simulation model in a computer format compatible with ahigh-level programming language, (HLL) and in a format compatible with ahardware description language (HDL).
 17. Method according to either ofclaims 15 and 16, wherein the configuration definition file (FCONF)comprises, for each component, at least one part in HDL-type language,said part in HDL-type language providing an interface with other models.18. Method according to claim 17, wherein the models that include a partin HLL-type language include interface adapters.
 19. Method according toclaim 18, wherein the Configurator system chooses each interface adaptermodel as a function of the connection coherency rule table (TRCOH). 20.Method according to claim 19, wherein the connections of the physicalsignals are specified by “Ports,” each port being an arbitrary selectionof the signals of the HDL-type interface of a component by means ofregular expressions based on the names of these signals, and beingconstituted by regular expression/substitute expression pairs, theseexpressions being successively applied to the name of each signal of theHDL-type interface, and if the final substitution is identical for twosignals, the latter are connected to one another, the connection beingstored in the wiring table (TCAB).
 21. Method according to claim 20wherein, each interface adapter being shared among several modelsconnected to the same port, only one of these models transmits signalsthrough said port.
 22. Data processing system (40) for automaticallygenerating a global simulation model of a configuration of fixedfunctional blocks, mutually connected by interworking connections so asto constitute the global simulation model of an architecture comprisingmodels of integrated circuits under development that can constitute amachine that conforms to the functional specification of aconfiguration, this system being characterized in that the dataprocessing system (40) uses a Configurator program (PROGCONF) thatincludes means for creating a simulation of the wiring by applyingstored regular expressions, and for using a configuration definitionfile (FCONF) in a high level language, a component and connection ruletable (TCRC) describing the properties (type, HDL-type interfaces,ports, constructors of HLL class objects, etc.) of the softwarecomponents for simulating the circuit, a connection coherency rule table(TRCOH) in a high level language (HLL), means for instantiating theelements resulting from the configuration definition file (FCONF), andan HLL code generator that combines the parameters of the componentswith the connection rules.
 23. System according to claim 22,characterized in that there are at least five types of components:Active Components, Monitoring and Verification Blocks, IntermediateBlocks, System Blocks and Global Blocks.
 24. System according to claim23, characterized in that it is equipped to perform a conformity checkof the connections by comparing the instance connection table (TCINST)with a table of coherency rules (TRCOH) for the physical connectionsbetween the models chosen from the blocks constituting the global model.25. System according to claim 24, characterized in that it is designedto compare the connection table of the real instances (TCINST) betweenblocks to the connection coherency rule table (TRCOH), in order todetect any incompatibilities between the ends of the connections betweenblocks, and in such a case to specify, and add into the connectioncoherency rule table (TRCOH), a functional adapter block (IntermediateBlock) (101) inserted into the connection in question.
 26. Systemaccording to any of claims 22 through 25, characterized in that thecomponent and connection rule table (TCRC), which includes theproperties of the components, contains global parameters common to allof the component types and exists in the form of a table distributedinto one or more tables, which may or may not be associative, whereinthe entries are names designating all of the possible models for thesame component.
 27. System according to claim 26, characterized in thatthe associative tables can contain the description, either in the formof parameter sets or in the form of references to procedures thatgenerate the required values, the entries of these associative tablesbeing names designating all of the possible models for the samecomponent and forming a character string containing predeterminedspecial identifiers, replaced by the values calculated by theConfigurator system.
 28. System according to claim 27, characterized inthat at least three selectors indicate the instance to be used, thelatter being transmitted as a parameter to a constructor of an HLLobject: a first selector indicates the current instance (“item”), asecond selector specifies the instance connected to the other end of theport, a third selector indicates the composite instance corresponding tothe active Component containing the observation port.
 29. Systemaccording to any of claims 22 through 28, characterized in that theConfigurator system uses one or more connection coherency rule tables(TRCOH), which represent the rules for interconnecting the componentsand for inserting intermediate components, one or more component andconnection rule tables (TCRC), which represent the system-levelconnection rules and the rules for generating connections between thesignals, and one or more source file formatting tables (TFMT), whichrepresent the rules for generating instances of HLL-type objects. 30.System according to any of claims 22 through 29, characterized in thatthe Configurator system uses: an HLL base class for uniquely identifyingeach object instantiated and for polling the configuration, means forgenerating and automatically instantiating System Blocks, means fortables associating the signals connected together under the unique nameof the connecting wires means for using a formatting table to generatethe source files in HDL and HLL.
 31. System according to any of claims22 through 30, characterized in that the operator functionally specifiesthe configuration in the highest level language as much as possible, andcompletes the functional specification with the components in the lowestlevel language.
 32. System according to any of claims 22 through 31,characterized in that the following entries in the hash define thecomponent Type (for example DUT (HDL model), XACTOR (transactor),MONITOR, VERIFIER or other types), and corresponds each Component Typeto a hash, in turn composed of the following entries: a first entryReqModule contains the name of the HDL module of the component and thename of the corresponding source file, a second entry Connect is thedefinition of the method for selecting the signals that are part of aPort, this description being composed of a set of entries indexed by thename of the Port; the configurator associates each Port name with atable of regular expressions and a pointer to a signal connectionprocedure that controls the application of these expressions to thenames of the signals of the interface of the component.
 33. Systemaccording to claim 32, characterized in that the generic structure ofthe active Components includes a Block containing the HDL descriptionand a Block in HLL that provides the access paths to the HDL resources,and if necessary, a description of the block in HLL; the set of signalsof the HDL block constitute the interface of the containing Block,formed by Ports, which are arbitrary logical selections of the signalsof an interface, and by interface adapters, which are the software partsthat handle, in each Port, the two-way communication between the partsin HLL and those in HDL, the interface adapters being chosen by theConfigurator system.
 34. System according to claim 33, characterized inthat the Ports are specified in the form of regular expressions, whichserve both to select the subsets of signals to be connected and todefine the connection rules.
 35. System according to any of claims 22through 34, characterized in that the Configurator system generatesso-called Transfer Components, which are inserted on each side of thecutoff to the servers, these components simply being wires for theinputs and registers for the outputs.